The push-to-talk over cellular (PoC) communication service enables a user of a mobile radio subscriber unit to convey voice data simultaneously to one or more receivers.
For this purpose, a special PoC key is typically provided on the mobile radio subscriber unit, after the operation of which the user can begin speaking voice data.
The voice data are usually already distributed, that is to say conveyed to the desired receiver or receivers, by means of a mobile radio communication network while speaking. This process is called “streaming”.
The conveying is done in half-duplex method, that is to say during the speaking and during the transmission, only the sender, that is to say the user who speaks and sends the voice data, can transmit voice data to the receivers but the receivers cannot, at the same time, send voice data to the sender. In particular, the sender cannot be interrupted by the receivers.
From the point of view of the user, a communication by means of PoC clearly corresponds to the conventional CB radio, but with the extension that the transmitter can convey voice data throughout the world to receivers who can be reached by means of the appropriate switching technology of at least one mobile radio communication network.
If a user of PoC wishes to send voice messages to the same receiver more frequently, PoC will enable him to define personal fixed user groups. For example a user of PoC can define a group with the designation “friends” which has corresponding members and their respective address, for example an SIP URL (Session Initiation Protocol Uniform Resource Locator) in the form of a telephone number or in the form of an SIP address.
For this group, a separate group address in the form of an SIP URL can then be assigned and when a PoC communication is set up, that is to say a communication session by means of PoC, specifying the group address which is initiated by a user, all members of the group are addressed by a PoC server and invited to join the PoC communication.
The prerequisite for a member of the group being invited is that the member is registered in the mobile radio communication network by means of which the PoC used is provided, i.e. is on-line.
Users of PoC who are actively involved in a PoC communication, that is to say as transmitter or passively, that is to say as receiver, will be called PoC participant in the PoC communication in the text which follows.
At present, standardization work for standardizing the PoC communication service is being carried out as part of the PS (packet-switched) domain of UMTS (Universal Mobile Telecommunications System) communication systems and/or as part of the PS domain GPRS (General Packet Radio Service) of GSM (Global System for Mobile Communication) communication systems. This standardization work is taking place within the framework of the standardization organizations OMA (Open Mobile Alliance) and 3GPP (3rd Generation Partnership Project). The protocols used in this standardization work are partially defined in the standardization organizations of the IETF (Internet Engineering Task Force).
It is provided that PoC is implemented, among other things, also on the basis of IMS (Internet Protocol based Multimedia Subsystem) communication systems in which the SIP (Session Initiation Protocol) signaling protocol and its extensions are used.
As mentioned above, in PoC voice data are transmitted in half-duplex and as an illustration, only one PoC participant is allowed to speak at any time of a PoC communication, and all other PoC participants can only receive, that is to say cannot send out any voice data. Within a PoC communication, therefore, only one PoC participant has a right to talk at any time, that is to say the right of sending out voice data to other PoC participants during the PoC communication. During a PoC communication, the right to talk is typically issued successively to different PoC participants. The administration and issuing of the right to talk is called floor control or talk burst control and is performed by a controlling PoC server which is called PoC server controlling function, or via a talk burst control server.
During a PoC communication, floor control is performed in accordance with the basic principle that the PoC client unit used by a PoC participant requests the right to talk from the controlling PoC server and the controlling PoC server thereupon refuses or grants the right to talk to the PoC client unit and correspondingly signals this to the PoC client unit. A PoC client unit is refused the right to talk, for example if another PoC client unit has the right to talk at the time at which the PoC client unit requests the right to talk.
Table 1 contains a list of the messages, defined in accordance with the prior art for the talk burst control during a PoC communication.
TABLE 1Direction oftransmission ofDescription of thethe messageMessage namemessageClient → ServerTalk burstA PoC client unit asksrequestthe controlling PoCserver whether it canreceive the right totalkServer → ClientTalk burstThe controlling PoCconfirmserver confirms theresponseright to talk to theinquiring PoC clientunitServer → ClientTalk burstThe controlling PoCreject responseserver denies theinquiring PoC clientunit the right to talkServer → ClientReceiving talkThe controlling PoCburstserver informs all PoCindicationclient units (exceptthe PoC client unitwith the right to talk)that the right to talkhas been issued andthus voice messages arenow also sent outClient → ServerTalk burstA PoC client unit withcompletedthe right to talkindicationinforms the controllingPoC server that itgives up the right totalkServer → ClientNo talk burstThe controlling PoCindicationserver informs all PoCclient units thatcurrently nobody hasthe right to talk andthus also no voicemessages are sent outServer → ClientStop talk burstThe controlling PoCindicationserver withdraws theright to talk from aPoC client unit withthe right to talk
The messages contained in Table 1 are implemented as RTCP APP packets, that is to say by means of the packet type for application-specific functions (APP) of the real-time control protocol (RTCP). The specifications of the respective RTCP APP packets are described in Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 1.0.
The binary floor control protocol (BFCP) is described in The Binary Floor Control Protocol (BFCP)—ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-xcon-bfcp-01.txt.
The specification of RTCP is described in RFC3550 “RTP: A Transport Protocol for Real-Time Applications”, Network Working Group, July 2003.